Codex CLI の承認と実行制御

1. 公式レシピ

代わりに、代表的な用途に対応するフラグの組み合わせがレシピとして示されている。

これの中から良さげなものを選ぶところからだと入門しやすい。

https://scrapbox.io/files/6960d03fbbea20e9c5a06d53.png

A：自動編集・自動実行（デフォルト）

codex --full-auto

ワークスペース内では自動で読み取り・編集・実行が進む

ワークスペース外の編集やネットワークアクセスを要する操作では承認が挟まる。

B：編集確認・実行確認

codex --sandbox read-only --ask-for-approval never on-requests

C：読み取り専用（コード編集，コマンド実行不可）

codex --sandbox read-only --ask-for-approval never

ファイルの読み取りのみが許可され、編集やコマンド実行はできない。

D：自動編集・実行確認

codex --sandbox workspace-write --ask-for-approval untrusted

作業ディレクトリ内での読み書きと実行が可能になる一方、信頼されていないコマンドについては承認が求められる。

自動化と安全性のバランスを取りやすい構成である。

E：フルアクセス（非推奨）

codex --sandbox danger-full-access

自動操作範囲をディレクトリ外まで広げる。

2. 権限制御の仕組み

1に述べたレシピはいずれも、固定の「モード」ではない。

「何ができるか（Sandbox）」と「どこで人が介入するか（Ask for approval）」という 2 つの独立した設定軸の組み合わせとして理解できる。

Sandbox（sandbox mode）

Sandbox は、エージェントが実行可能な操作の上限を定める。読み取りだけ許すのか、作業ディレクトリ内での書き込みや実行まで許すのか、あるいはシステム全体へのアクセスを許すのか、という境界をここで決める。

重要なのは、Sandbox が最上位の制約である点である。

Sandbox で禁止された操作は、どのような承認設定をしていても実行できない。

このため、安全設計ではまず Sandbox を決め、その範囲の中で運用の自由度を調整する。

table:sandbox

項目 読み取り 書き込み コマンド実行 ネットワーク

read-only 作業ディレクトリ 不可 不可 -

workspace-write 作業ディレクトリ 作業ディレクトリ 作業ディレクトリ 無効（有効化可能）

full-access（非推奨） システム全体 システム全体 システム全体 -

Ask for approval（approval policy）

Ask for approval は、Sandbox で許可された操作について、人間の確認を挟むかどうかを制御する。

危険度の高い操作だけ止めるのか、失敗時だけ止めるのか、モデル判断に委ねるのか、あるいは一切止めないのか、といった方針を選べる。

ここで承認が必要と判断された場合、実行前に対話的な確認が行われる。

承認を行わない設定にすれば、許可された範囲の操作は自動で進む。

table:approval

untrusted 信頼できないコマンド（ホワイトリスト外の動作）に対して承認を求める

on-failure 通常は承認なしでコマンドを試すが、失敗した場合に承認を求める

on-request モデル自身がどの操作に承認を求めるかを判断する

never ユーザーに承認を求めない

プリセットの位置づけ

内部的には Sandbox と Ask for approval の組み合わせをまとめて指定しているだけであり、利便性のためのショートカットである。

したがって、挙動を正確に理解・制御したい場合は、最終的には Sandbox と Ask for approval の設定に分解して考えることになる。

3. 運用設計の考え方

運用を設計する際は、次の順で考えると整理しやすい。

まず、Sandbox で「どこまで触らせてよいか」という上限を決める。

次に、その範囲の中で Ask for approval を使って「どの程度人間が介入するか」を調整する。

公式レシピやプリセットは、その典型的な組み合わせをあらかじめ用意したものと位置づける。

この順序で考えることで、利用場面と設定の対応関係を一貫した形で説明できるようになる。